Amazon Redshift: 『うるう秒』対応について
来年2017年01月01日、下記ニュースリリースにもありますように『うるう秒』が挿入されます。具体的には2017年01月01日08時59分59秒の後に『2017年01月01日08時59分60秒』が1秒追加される形となるのですが、この部分のデータがデータベースにどのように影響するのか、という部分についてはインフラやアプリに関わる人達に取っては気になるところです。私も直近、Amazon Redshiftでこの事象について確認しておくケースがありましたので、その内容を簡単ではありますが書き記しておこうと思います。
結論
結論から言いますと、大丈夫です。
AWSの公式ブログでも以前、このトピックについて言及していたものがあり、この中にAmazon Redshiftも含まれています。基本的にはデータベース周りについては『うるう秒』に関する対応はAWS側でよしなに対応してくれるので心配ありませんよ、という感じですね。
Amazon Redshiftにおける『うるう秒』の挙動確認
では、実際にAmazon Redshiftでは『うるう秒』がどのように対処対応されているのか、実際にデータを使って確認してみたいと思います。まずはINSERT文。id=2のデータが該当するデータとなりますが、INSERT自体は特に問題無く行われ、値としては2017-01-01 09:00:00に変換されています。
# CREATE TABLE IF NOT EXISTS public.leap_sec_test ( id INT NOT NULL, regist_timestamp TIMESTAMP NOT NULL ); CREATE TABLE # INSERT INTO public.leap_sec_test VALUES(1, '2017/01/01 08:59:59'); INSERT 0 1 # INSERT INTO public.leap_sec_test VALUES(2, '2017/01/01 08:59:60'); INSERT 0 1 # INSERT INTO public.leap_sec_test VALUES(3, '2017/01/01 09:00:00'); INSERT 0 1 # SELECT * FROM public.leap_sec_test ORDER BY id; id | regist_timestamp ----+--------------------- 1 | 2017-01-01 08:59:59 2 | 2017-01-01 09:00:00 3 | 2017-01-01 09:00:00 (3 rows)
次いでCOPY処理。こちらも上記同様、うるう秒の値を含むデータを用意し、
id,regist_timestamp 4,2017-01-01 08:59:59 5,2017-01-01 08:59:60 6,2017-01-01 09:00:00
COPY処理実施。上記INSERT文と同様、秒が所定の内容に変換される形で特に問題無く処理が行えました。
# COPY public.leap_sec_test FROM 's3://xxxxxxxxxxxxxxxxxxxx/leap_sec.csv' CREDENTIALS 'aws_access_key_id=XXXXX;aws_secret_access_key=YYYYY' CSV DATEFORMAT 'YYYY-MM-DD HH24:MI:SS' IGNOREHEADER AS 1; INFO: Load into table 'leap_sec_test' completed, 3 record(s) loaded successfully. COPY Time: 4217.451 ms # SELECT * FROM public.leap_sec_test ORDER BY id; id | regist_timestamp ----+--------------------- 1 | 2017-01-01 08:59:59 2 | 2017-01-01 09:00:00 3 | 2017-01-01 09:00:00 4 | 2017-01-01 08:59:59 5 | 2017-01-01 09:00:00 6 | 2017-01-01 09:00:00 (6 rows)
まとめ
という訳でAmazon Redshiftにおける『うるう秒』の対応、特に利用者側で対応をしなければならない、という事は無さそうです。良かった良かった。こちらからは以上です。